1. Field of the Invention
This invention relates generally to video communications, and, more particularly, to methodologies and concomitant circuitry for dynamically injecting video coding software into a transmitted video stream so that receivers are capable of playing video encoded in any format.
2. Description of the Background
Currently there are many different types of video coding standards which can only be utilized for video playback at a receiver if the receiver has the correct software pre-loaded. As the number of different encoding techniques grows and existing video encoding software is updated, the receiver must load all the new and updated software in order to play current video streams.
Representative of the conventional arrangement to transmit video frames via packets through a packet network is the high-level depiction of video system 100 shown in FIG. 1. Each video frame produced by a standard source (not shown), as exemplified by frame 110 serving as the input to transmitter 101, is compressed by encoder 120 with reference to an encoding program stored in program memory 125, and the encoded output appearing on lead 121 is formatted into packets 131 by data packetizer 130. Transmitter processor 135 controls the interactions of encoder 120 with program memory 125, and also provides the necessary control information so as to form packets 131. In turn, packets 131 are transmitted via packet network 140 as propagating packets 132 which are detected by receiver 102, where the packets are processed by data extractor 150 to produce, on lead 151, the received counterpart of compressed output 121 in transmitter 101. The resulting data stream on lead 151 is decompressed by decoder 160 to produce received frame 111, a reproduced version of original frame 110.
In order to reproduce frame 111, it is necessary for decoder 160 to have available decoding software which corresponds to the encoding software of encoder 120. Conventionally this is accomplished by the prior loading and storing of the corresponding decoding software in decoder 160 so as to display the video stream. Unfortunately from the point of view of loading and storage, there are many different video coding standards, including MPEG-1, MPEG-2, MPEG-4, MPEG-7, JPEG, H.261, and H.263. The standards also keep evolving. Thus, it is sometimes the case that receiver 102 receives a video stream 132 which cannot be played back because decoder 160 lacks suitable decoding software, either because decoder 160 has not been loaded with the commensurate software or the decoder is not compatible with the older or newer version of compressed video. Currently users of system 100 are responsible for installing each unique piece of software that may be required in decoder 160 in order to decode a particular video stream.
The subject matter of the present invention relates to: (a) encapsulating the appropriate video decoding software, including the encoding algorithms, via transmitter 101; (b) bundling the decoding software with the actual video packet streams; and (c) transmitting the encoded video along with specific decoding instructions to receiver 102. This provides any properly equipped receiving terminal with the ability to play any type of encoded video stream without having the associated decoding software pre-loaded, thus creating a highly flexible and dynamic video transmission environment. The methodology and concomitant circuitry of the present inventive subject matter engenders what is referred to as xe2x80x9cactive techniquesxe2x80x9d for video.
Recently, the notion of xe2x80x9cactive networkingxe2x80x9d has been introduced; active networking is intended to effect a significant change on the historical network paradigm, namely, a change from a passive carrier of analog/digital signals to a more general computational ability associated with network components, and has especially been applied to switches and/or routers used to provide telecommunications services. However, such efforts to this point in time have been devoted more to outlining the benefits that such a paradigm could achieve, without elucidating specifics of such an approach except in a few special cases.
For example, the paper entitled xe2x80x9cOn Active Networking and Congestionxe2x80x9d as authored by Bhattacharjee, Calvert, and Zegura (BCZ) in January, 1996 and published as Georgia Institute of Technology Technical report GIT-CC-96/02, focuses on applying active networking concepts to handling network congestion. In BCZ, the model of what happens when a packet arrives at a node (used interchangeably with switch or router) is as followsxe2x80x94for purposes of discussion, a packet is composed of a header part and a payload part:
(1) The output destination port for the packet is computed as usual.
(2) If a packet contains a valid Active Processing Function Identifier (ACPI), it is sent to an active processor and processing continues; otherwise, it is transmitted as usual.
(3) The function specified in the ACPI is computed, using the packet""s association descriptor and user data as inputs.
(4) If the result of the function is transformed data (e.g., reduced length), the packet""s network-level header and ACPI are recomputed as necessary; the node""s state is updated as required by the specified function.
(5) The (possibly modified) packet is transmitted to its next-hop node.
It is extremely important to reiterate that the above procedure requires an Active Processing Function Identifier (ACPI) to differentiate between conventional processing and additional, that is, active processing. As BCZ further point out, the obvious place to put the ACPI is in the same header used to switch the packet. However, BCZ concludes that such an approach is unacceptable for at least two reasons. First, the approach does not work for ATM or any other technology where the switched unit is too small to accommodate additional overhead of the ACPI. And second, the approach is not backward-compatible, requiring that all network protocols become xe2x80x9cactive-awarexe2x80x9d. BCZ proposes that an alternative to placing the ACPI in the network header itself is to define a xe2x80x9cgenericxe2x80x9d location for the ACPI function, sufficiently high in the protocol stack that the additional processing overhead is not prohibitive, but sufficiently low in the protocol stack to allow its location by switching nodes without too much knowledge of higher-level protocols. Thus, BCZ immediately rules out the use of the packet itself for differentiating between conventional and active processing. However, use of the packet (either the header, payload, or both) overcomes what BCZ deems to be unacceptable, that is, use of the packet itself eliminates additional packet overhead, and network protocols need not be xe2x80x9cactive-awarexe2x80x9d.
Moreover, in the BCZ approach, there is no program portion in the packet. Programs are embedded into the node. There is only a set of predefined computations which can be performed in the node. A node which has the computational power is called an active processor (AP). Header information in each packet specifies which computation is to be performed on it. For example, for MPEG packets, the fields in the header indicate the priority of particular packets (for example, I, P, and B frames, as further discussed below). This priority is used in the AP to decide which packet should be dropped to avoid congestion.
Consequently, the prior art is devoid of teachings or suggestions relating to: encapsulating the appropriate video decoding algorithms and software, bundling them with the actual video streams, and transmitting the encoded video along with specific decoding instructions to the receiving terminal, which then allows properly equipped receiving terminals the ability to play any type of encoded video stream without having the associated decoding software pre-loaded, thus creating a highly flexible and dynamic video transmission environment.
Shortcomings and limitations of the prior art are obviated, in accordance with the present invention, by a methodology and concomitant circuitry wherein, generally, the programming code to decode encoded video is bundled with the encoded video in the same propagation stream so that the appropriate decoding program is readily available without the need to configure the receiver beforehand.
Broadly, in accordance with one method aspect of the present invention, a method for transceiving a real-time video frame includes the following procedure: (a) determining a decoding program for the compressed data file; (b) independently partitioning the compressed data file into data sub-files and the decoding program into decoding sub-programs; (c) propagating a sequence of the sub-files and the subprograms; (d) detecting the sequence to determine the sub-files and the sub-programs; and (e) combining the sub-files to reproduce the compressed data file and combining the subprograms to reproduce the decoding program.
Broadly, in accordance with another method aspect of the present invention, a method for transceiving a real-time frame includes the following procedure: (a) determining a decoding program for the compressed data file; (b) independently partitioning the compressed data file into data sub-files and the decoding program into decoding sub-programs; (c) propagating a sequence of active packets composed of the sub-files and the sub-programs; (d) detecting the sequence of active packets to determine the sub-files and the sub-programs; and (e) combining the sub-files to reproduce the compressed data file and combining the sub-programs to reproduce the decoding program.